IBIS Macromodel Task Group

Meeting date: 06 February 2024

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora System:                Dian Yang
                              Raj Raghuram
Cadence Design Systems:     * Ambrish Varma
                            * Jared James
Dassault Systemes:            Longfei Bai                             
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                              Kinger Cai
                            * Chi-te Chen
                              Liwei Zhao
                              Alaeddin Aydiner
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:                 Chulsoon Hwang
                              Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
                              Randy Wolff
Teraspeed Labs:               Bob Ross
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

Michael reported that a third-party open-source tool developer had approach him
at DesignCon.  The developer noted that our parser source code (tschk in this
case) is not open source.  The developer would be interested in utilizing the
freely distributed parser executables if they provided access to data structures
containing the parsed data.  They asked for an API or some other way to get
access to the data structures, as opposed to the executable's current operation
as a syntax checker.  The group decided this topic could best be handled in the
Quality task group.
  
-------------
Review of ARs:

Michael: Develop a new clarification BIRD to more clearly define relationships
         between concepts, terms, and parameters such as block, block size,
         wave_size, etc.
         - In progress.  Michael said we might have further discussion during
           this meeting about what needs to be clarified.
         
Michael: Send draft2 of BIRD229.1 to the ATM list.
         - Done.  Michael sent draft2 to the ATM list on January 23, 2024.
         
Michael: Develop a full syntactically complete example demonstrating BIRD229.1.
         - Done.  Michael said that unless there are any functional changes to
           the BIRD, version 2 of the example, which he had posted to GitHub,
           is complete.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the January 23rd
meeting.  Ambrish moved to approve the minutes.  Walter seconded the motion.
There were no objections.

--------------
New Discussion:

BIRD229.1 draft3:
Michael shared BIRD229.1 draft3.  He noted that draft3 was a work in progress
and contained several editorial corrections he had received after sending out
draft2.  Michael reviewed the changes in draft2, including:
- Replacing the phrase "size of each block of data" with "number of samples
  in the data passed to and received from" when describing what is specified
  by wave_size.  This is to avoid potential confusion related to assumed units
  for the undefined term "block size".
- The "time duration" of a block of data was replaced with "number of samples"
  for additional clarity.
- The phrase "number of UI" was replaced with "number of symbol times".

Arpad asked for confirmation that a UI (unit interval) corresponds to a symbol
time for any PAMn.  Walter confirmed, and the group agreed that UI is symbol
time.

Michael introduced a new change he wanted to make in draft3.  He said that he
had originally made AMI_output_parameters_file optional in an attempt to make
things as convenient as possible for model makers.  However, given that we are
relying on this BIRD to provide the information necessary to address parser
BUG227 (AMI root name checking), he wanted AMI_output_parameters file to be
required instead of optional.  He said that even if a model has no parameters
to return, it should return the root name in AMI_parameters_out.  By making
AMI_output_parameters_file required, we can ensure that [AMI Test Configuration]
allows the parser to check the returned root name.  This would resolve BUG227.
No one objected to making AMI_output_parameters_file a required subparameter.

Walter offered comments on the proposal.  He said his organization creates AMI
models, and they already develop tests as part of that process.  They would plan
to give their designers the ability to take the tests they already have and
convert them into the format of BIRD229.1.  However, he said they typically only
use the .ibs file as a minimal required wrapper.  He asked why we would want to
put all of this new test information in the .ibs file at all.  He suggested that
it would be better to add it to the .ami file.  We could simply add an AMI
Reserved parameter to point to a new file containing the test configuration
information.  He said that the existing proposal might force the model maker to
add this test information to many different .ibs files that utilize the same
underlying .dll/.so.  Arpad agreed that Walter's proposal might be more
efficient, because it would avoid repeating the same information in multiple
[Model]s that contained [Algorithmic Model]s that relied on a common .dll/.so.

Michael asked how Walter's proposal would replace the functionality provided by
the Executable_index and Direction subparameters.  He said Executable_index was
there to provide multiple sets of golden result test data for various operating
systems, 32 or 64 bit architectures, etc.  This was anticipating that different
versions of the same .dll (same underlying code) might use the same .ami file
but return slightly different results.

Walter said a comparison looking for strict equality was often going to fail,
no matter how many different sets of results we provided.  The exact same .so
can return slightly different results on different machines.  He said a real-
world comparison would have to be toleranced, and this could involve concepts
like relative tolerance and absolute tolerance.

Michael said the precision of the data provided in the [AMI Test Configuration]
results files might differ from what is being generated on a given test machine,
and he agreed that a naive comparison looking for strict equality would likely
fail.  He said something like FSV or a different type of comparison algorithm
might be valuable, but he wasn't proposing any particular form of comparison.
However, with Executable_index, he was addressing the concern that the golden
data sets might be slightly different for various operating systems,
architectures, etc.  He said perhaps we need to introduce a precision
specification requiring the model maker to provide a certain minimum precision
in the golden results files.  Michael said he could envision ways in which the
information provided by Executable_index could be added to the .ami file, but we
would have to provide more information in the .ami file and might need to have
a different .ami file for each of the different builds of the same .dll/.so.

Walter said the two different approaches could provide the same functionality,
but he thought the simplicity of putting the information in the .ami file
outweighed the extra flexibility of the current BIRD229.1 proposal.

Arpad noted that the results files in BIRD229.1 are in ASCII format.  He said
the precision of the numbers provided in ASCII format files is typically much
lower than that needed to detect the small OS to OS or machine to machine
differences.  Arpad asked whether we should consider providing the results data
in binary format to facilitate higher precision comparisons.  Jared asked
whether the user or tool could infer the precision to be used for the comparison
from the precision of the data provided in the ASCII file.  Michael noted that
someone at DesignCon had asked whether we should support binary format in order
to minimize the size of the waveform files.

Ambrish said he thought the approach in BIRD229.1 was an effective use of the
existing .ibs wrapper around the .ami model.  Walter said he would prefer not to
put the information in the .ibs file itself, but his organization would follow
BIRD229.1 if it is approved.

Michael said he would introduce the change to make AMI_output_parameters_file
a required subparameter and send out draft3.

- Curtis: Motion to adjourn.
- Jared: Second.
- Arpad: Thank you all for joining.

New ARs:
         
Michael: Send draft3 of BIRD229.1 to the ATM list.

-------------
Next meeting: 13 February 2024 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
